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(57) Abrege : Un terminal (2) comporte une premiere famille d'applications (4) et une seconde famille d'applications (3) ayant des 
capacites de communication sur un r£seau (R) plus 6tendues que la premiere famille. Le proceed comprenant les etapes suivantes: /a/ 
un composant de confiance (8) appartenant a la seconde famille d'applications obtient un 6nonc6 de question a poser a un utilisateur 
de la premiere unit£ dans le cadre d'une application de la premiere famille; fbl le composant de confiance presente la question a 
l'utilisateur et recueille sa nSponse; et /c/ le composant de confiance transmet a un serveur distant, par Tinterm^diaire du r6seau, un 
message identifiant la question et indiquant la reponse recueillie. Ce message est transmis dans des conditions inaccessibles aux 
applications de la premiere famille, ce qui garantit au serveur qu'il traduit bien la reponse apportee par l'utilisateur. 
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PRO CEDE DE COMMUNICATION DE CONFIANCE ENTRE DEUX UNITES 

La presente invention concerne les terminaux informatiques personnels 
permettant a des utilisateurs d'acc6der 3 des services en ligne. 

5 De tels terminaux peuvent notamment etre des telephones utilisant le 

protocole d'application sans Til (WAP, "wireless application protocol"), des 
ordinateurs de bureau, des ordinateurs portables ou des assistants numeriques 
personnels (PDA, "personal digital assistant"), lis ont en commun la 
caracteristique d'etre reli6s a un r6seau de donnees num6rique, qui dans 

10 beaucoup de cas pratiques est un reseau fonctionnant selon le protocole IP 
("Internet protocol"), notamment I'lnternet. 

Dans ces terminaux, il est possible d'installer diverses applications. 
Parmi ces applications, il est frequemment fait une distinction selon divers 
criteres tels que leur origine, le degre de confiance qui leur est accorde par un 
15 administrateur, etc., qui r6sulte en des capacites differentes pour certaines 
applications par rapport a d'autres. 

Par exemple dans les systemes fonctionnant sous le systeme 
Sexploitation dit "Unix", les droits d'execution des applications de classe 
"setuid root" sont les droits maximaux, de niveau administrateur, alors que les 

20 droits d'ex^cution des autres applications sont simplement les droits de 
Tutilisateur qui lance Tapplication. Autre exemple, dans les navigateurs web 
comportant une machine virtuelle Java, les applications, appelees "applets", 
telechargees depuis un site web donne sont limitees quant d leurs capacites 
d'acceder au reseau, c'est-a-dire qu'elles ne peuvent emettre des requetes du 

25 protocole HTTP ("hypertext transfer protocol") que vers ce site web. 

Certains de ces droits d'exScution des applications sont purement 
locaux. C'est le cas par exemple du droit de prendre le contrdle de P6cran d'un 
terminal, ou du droit d'avoir connaissance de toutes les touches enfonc6es sur 
le clavier du terminal, meme pour d'autres applications. 

30 Mais d'autres droits d'execution sont observables a distance. C'est le 
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cas par example du droit d'emettre des paquets IP quelconques, y compris des 
paquets IP qui ne se conformeraient pas aux formats des protocoles de 
transport les plus courants, a savoir TCP ("transmission control protocol") ou 
UDP ("user datagram protocol"). Dans les systemes Unix, ce droit n'est pas 

5 donne aux applications qui ne sont pas de classe "setuid root". En utilisant 
cette difference de capacite d'envoi de requetes, un observateur a distance tel 
qu'uii serveur peut determiner qu'un paquet donne a ete emis par une 
application de classe "setuid root": s'il observe que ce paquet ne se conforme 
pas au format TCP ou UDP, il s'agit forcement d'une application de classe 

10 "setuid root"; sinon, il se peut qu'il s'agisse d'une application sans droits 
privileges. 

Dans le cas des applets dans les navigateurs, sur les ordinateurs 
personnels, les capacites d'envoyer des requetes HTTP sont limitees au seul 
site d'oD I'applet a ete telechargee. Pour chaque requete HTTP recue, un 
15 serveur web peut done deduire qu'elle provient soit d'une applet presente sur le 
site soit d'une autre application (par exemple le navigateur). Mais en tout cas, 
les requetes recues par un serveur web ne proviennent pas d'applets 
"etrangeres" presentes sur d'autres sites. 

On s'interesse ici au probleme de savoir comment un serveur peut 
20 recueillir de facon securisee I'accord de I'utilisateur sur une question donnee. 
La question a poser a I'utilisateur doit etre presentee a I'utilisateur par 
I'intermediaire d'une application sur son terminal, [.'application recueille I'accord 
(ou le desaccord) de I'utilisateur, puis transmet une indication correspondante 
au serveur. 

25 Le serveur regoit done des messages sur le reseau et les interprete 

comme I'accord (ou desaccord) de I'utilisateur. II doit pour cela faire 
I'hypothese que Papplication a bien presente la question a I'utilisateur et a 
recueilli son accord en toute honnetete. Le serveur suppose done que 
I'application n'est pas un "cheval de Troie" qui aurait par exemple presente une 

30 question diff6rente a I'utilisateur, ou bien qui n'aurait tout simplement pas 
presente la question a I'utilisateur mais fait comme si celui-ci ayait ete d'accord. 
Pour proteger I'utilisateur contre d'eventuels programmes du genre "cheval de 
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Troie", il importe de s'assurer de cette hypoth§se de confiance. 

II existe plusieurs moyens de satisfaire raisonnablement cette 
hypothese de confiance en I'application. 

Certaines applications sont reconnues §tre "de confiance n . Une telle 
5 application est par exemple le navigateur WAP. Un serveur peut avoir 
confiance en un navigateur WAP pour qu'il affiche une page posant une 
question a I'utilisateur et attende que l'utilisateur saisisse sa reponse. 

Dans le cas d'un terminal "ferme" (exemple: un Minitel), les 
applications presentes sur le terminal sont connues et ne peuvent pas etre 
10 changees au cours de la vie du terminal. Toutes ces applications sont 
reconnues "de confiance". 

L'ouverture d'un terminal fait reference a la possibilite offerte a 
l'utilisateur d'installer, et souvent de telecharger, de nouvelles applications 
destinees a etre executees par le terminal lui-meme. Des exemples de 
15 terminaux "ouverts", integrant cette possibilite, sont: 

• les telephones a telechargement duplications, par exemple de type 
Java MIDP ("Mobile Information Device Profile", Sun Microsystems, Inc.); 

• les navigateurs possedant des fonctionnalites dites de scripting, par 
exemple de type WMLScript (voir "WAP WMLScript Language 

20 Specification", version 1 .1 , WAP Forum, novembre 2001) ou ECMAScript 

(aussi appele JavaScript, voir "ECMAScript Language Specification", 
Standard ECMA-262, 3 e edition, decembre 1999), ou accueillaht des 
applets; 

• la plupart des PDA, fonctionnant sous les systemes d'exploitation 
25 PalmOS, WindowsCE, Symbian etc.; 

• les ordinateurs de bureau ou portables. 

Les terminaux "semi-ouverts" sont les terminaux ouverts dont certaines 
fonctionnalites ne sont pas directement accessibles aux applications instances 
par l'utilisateur ou telechargees. Par exemple, dans un terminal dont la seule 
30 "ouverture" est ECMAScript, les applications telechargees ne peuvent pas 
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acceder a toutes les fonctionnalites du reseau (par exemple, emettre des 
paquets IP quelconques). Ces fonctionnalites peuvent etre accessibles de 
fa9on indirecte et contrdlee. Par exemple, une fonction ECMAScrlpt peut 
commander le chargement d'une page via HTTP, ce qui utilise le reseau mais 
5 d'une facon contrdlee. 

. Dans des terminaux "semi-ouverts", il y a coexistence: 

• d'applications considerees comme "de confiance", par exemple parce 
qu'elles ont ete installees en usine par le fabricant du terminal, ou bien du 
fait de la garantie procuree par des moyens tels que la signature 

10 electronique de I'application etc.; 

• et d'autres applications qui peuvent etre installees sur le terminal par 
I'utilisateur lui-meme, a son libre choix, mais n'accedent pas aux memes 
droits que les applications de confiance. 

Les terminaux "completement ouverts", par opposition, sont les 
15 terminaux ouverts dans lesquels toutes les fonctionnalites sont accessibles aux 
applications telechargees. La notion d'ouverture d'un terminal depend dans 
une large mesure du contexte dans lequel on se place. Par exemple, 
differentes couches du modele OSI (lien / reseau / session / transport / ...) 
peuvent avoir diff6rents degr6s d'ouverture. 

2 o On s'interesse ici aux fonctionnalites observables a distance, depuis un 

serveur, c'est-a-dire aux fonctionnalites de r6seau. Dans ce cadre, le caractere 
"semi-ouvert" d'un terminal implique gen§ralement que des droits d'execution 
observables a distance, accessibles aux applications de confiance, ne sont pas 
accessibles aux applications sans confiance (par exemple, le droit d'emettre 

25 des requetes autres que HTTP sur un reseau IP). Ceci permet a un serveur de 
distinguer, parmi les requetes qui lui arrivent, celles qui proviennent 
d'applications de confiance et celles qui proviennent d'autres applications. 

Les "applets", que l'utilisateur installe a son libre choix, ne sont pas 
forcement de confiance pour acceder a n'importe quel serveur. Cependant, la 
30 restriction des requetes de chaque applet au site d'ou elle a ete telechargee 
permet a un site web de garder le contrdle sur les applets qui peuvent emettre 
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des requetes vers lui. II est done raisonnable que le serveur suppose que les 
applications presentant des questions a I'utilisateur ne sont pas des Chevaux 
de Troie. Ces applications sont done "de confiance", mais pour un site web 
uniquement. 

5 Dans les terminaux ouverts, il faut tenir compte de la possibility qu'un 

programme se comporte de facon trompeuse vis-a-vis de I'utilisateur (cheval 
de Troie). Ainsi, rien ne peut garantir a un serveur qu'une requete provient bien 
de I'utilisateur, et non d'un programme ayant simule I'accord de I'utilisateur au 
niveau du reseau. Ce risque mine la confiance que le serveur peut avoir dans 

10 les donnees qu'il recoit d'un client. L'hypothese selon laquelle les requetes 
adressees au serveur refletent les actions de I'utilisateur n'est pas raisonnable 
si un cheval de Troie a la possibilite de les envoyer a la place de I'utilisateur. 

La reponse classique au risque de cheval de Troie est de limiter les 
capacites des applications sans confiance. 

15 La limitation de remission des trames depuis les terminaux semi- 

ouverts se fait generalement de facon extremement stricte. Seules les 
applications de confiance sont autorisees a emettre certaines trames. Cette 
distinction est utilisee pour que le serveur n'accepte pas comme 
representatives de I'accord de I'utilisateur des trames emises par des 

20 applications sans confiance, susceptibles de trahir I'utilisateur. 

II devient done impossible a une application sans confiance d'emettre 
des trames vers un serveur. II est notamment impossible pour cette application 
de prouver a ce serveur I'accord de rutilisateur. Par exemple, il est impossible 
a une application sans confiance de proposer a I'utilisateur de payer en utilisant 
25 un serveur de commerce electronique. 

Pour une « applet », qui est restreinte a ne pouvoir emettre des 
requetes que vers le site web d'od elle a ete telechargee, la confiance n'est 
accordee que pour ce serveur. II est done possible a cette applet de recueillir 
I'accord de I'utilisateur et de transmettre le resultat au site web d'ou elle a ete 
30 telechargee. On fait alors l'hypothese — raisonnable — que le serveur n'a 
jamais propose de telecharger des applications de type "cheval de Troie". 
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Des systemes a base de cryptographie existent pour generer des 
signatures electroniques. Un exemple en est decrit dans la specification "WAP 
WMLScript Crypto Library", WAP Forum, juin 2001. Ces systemes peuvent etre 
utilises pour recueillir I'accord de I'utilisateur, ils font I'hypothese que le 

5 systeme est semi-ouvert, c'est-a-dire en Poccurrence que les fonctions d'acces 
aux cles cryptographiques ne sont pas directement disponibles aux 
applications sans confiance. L'acces aux cles cryptographiques est gere par un 
composant logiciel particulier, que nous appelons "composant de signature 
electronique", charge de recueillir I'accord de I'utilisateur pour le compte de 

10 I'application. Ce composant effectue de lui-meme I'enchaTnement d'operations 
suivant pour le compte duplications sans confiance: 



• afficher le texte a signer a I'ecran; 

• attendre confirmation de I'utilisateur; 

• si une confirmation est recue, utiliser les cles cryptographiques de 



• sinon, ne pas signer le texte affiche. 

Ceci permet done a des applications sans confiance d'obtenir une 
signature electronique de I'accord de I'utilisateur via le composant de signature 
electronique. Ce proced6 permet au serveur d'obtenir I'accord de I'utilisateur 
20 par rapport a un texte quelconque. 

II faut ici faire I'hypothese que le terminal n'est pas completement 
ouvert. S'il etait possible a une application sans confiance d'acceder 
directement aux fonctions cryptographiques, on ne pourrait pas savoir si I'appel 
aux fonctions cryptographiques a bien ete precede d'un affichage de la totalite 
25 du texte a signer ou si le terminal a bien attendu I'accord de I'utilisateur avant 
de proceder a la signature. 

D'autre part, ce procede met en oeuvre des techniques 
cryptographiques, qui peuvent s'averer couteuses en temps d'execution, en 
taille de messages echanges sur le reseau ainsi qu'en consommation 
30 electrique (important pour les terminaux portables). De plus, la legislation sur 
les techniques cryptographiques peut eventuellement restreindre la possibilite 
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I'utilisateur pour signer le texte affiche; 
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de recourir a ce precede. 

II est done souhaitable de fournir un comportement quaslment 
equivalent en termes d'ouverture aux applications sans confiance, mais sans 
recourir a la cryptographie. 

5 Un but de la presente invention est de permettre a une application 

"sans confiance" en milieu semi-ouvert de recueillir I'accord de I'utilisateur sur 
une question donnee, et d'en avertir un serveur distant en lui prouvant que cela 
a ete fait de facon honnete, 

L'invention propose ainsi un precede de communication entre une 
10 premiere unite et une seconde unite par I'intermediaire d'un reseau de 
telecommunication, dans lequel la premiere unite comporte une premiere 
famille d'applications et une seconde famille d'applications ayant des capacites 
de communication sur le reseau au-dela des capacites de communication des 
applications de la premiere famille. Selon l'invention, ce precede comprend les 
15 etapes suivantes: 

/a/ un composant de confiance appartenant a la seconde famille 
d'applications obtient I'enonce d'une question a poser a un utilisateur 
de la premiere unite dans le cadre de I'execution d'une application de 
la premiere famille; 

20 /b/ le composant de confiance presente la question par I'intermediaire 
d'une interface d'utilisateur et recueille une reponse de I'utilisateur; et 
Id pour au moins un type de reponse de I'utilisateur, le composant de 
confiance transmet a la seconde unite, par I'intermediaire du reseau, 
au moins un message identifiant la question presentee et indiquant la 

25 reponse recueillie, ledit message etant transmis dans des conditions 

inaccessibles aux applications de la premiere famille. 

Un autre aspect de la presente invention se rapporte a un composant 
togiciel de confiance pour la mise en oeuvre du precede ci-dessus au niveau de 
ladite premiere unite, ainsi qu'un terminal de communication, incorporant un tel 
30 composant logiciel de confiance. Ce composant de confiance appartient a la 
seconde famille d'applications precitee et inclut des instructions pour 
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commander les 6tapes suivantes lors de son execution dans la premiere unite: 

/a/ obtenir F6nonce d'une question § poser a un utilisateur de la premiere 
unite dans le cadre de I'execution d'une application de la premiere 
famille; 

5 /b/ presenter la question par rintermediaire d'une interface d'utilisateur et 

recueillir une r§ponse de Tutilisateur; et 
lol pour au moins un type de reponse de I'utilisateur, transmettre & la 

seconde unite, par rintermediaire du reseau, au moins un message 

identifiant la question presentee et indiquant la reponse recueillie, ledit 
10 message 6tant transmis dans des conditions inaccessibles aux 

applications de la premiere famille. 

D'autres particularites et avantages de la presente invention 
apparaTtront dans la description ci-apr§s d'exemples de realisation non 
limitatifs, en reference aux dessins annexes, dans lesquels les figures 1 et 2 
15 sont des schemas d'un systeme mettant en oeuvre I'invention. 

On cherche & permettre a une unite distante telle qu'un serveur 1 
d'obtenir de fagon sQre et souple I'accord de I'utilisateur d'un terminal semi- 
ouvert 2 relativement § une question donn§e. L'accord peut etre obtenu par 
des applications de confiance 3, comme dans le cas de la navigation, mais 
20 aussi depuis des applications sans confiance 4, ayant des capacites de 
communication plus restre'mtes (voire inexistantes) sur le reseau de 
telecommunication R utilise pour dialoguer avec le serveur 1 . 

On se place ici dans le cadre d'un terminal 2 faisant une distinction 
entre applications de confiance 3 et applications sans confiance 4. Cette 
25 distinction se traduit par des capacites distinctes d'emissioh de frames ou de 
requetes sur le reseau R. Les applications sans confiance 3 sont limitees dans 
les frames qu'elles peuvent emettre, ce qui, dans le schema de la figure 1 , est 
symbolise par une couche de controle 5 faisant partie des ressources 6 
d'acces au reseau dont est equip6 le terminal 2. 

30 La couche de controle 5 v§rifie que certaines propriet§s sont remplies 
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par les frames emises par les applications sans confiance 4. Si ces proprietes 
sont remplies, la couche de controle laisse passer les frames. Sinon, elle peut 
soit ne pas les laisser passer vers le reseau R et en prevenir I'application sans 
confiance 4 qui les a emises, soit modifier les trames pour les conformer aux 
5 contraintes des applications sans confiance. Dans ce dernier cas, la frame perd 
alors sa credibility aux yeux du serveur 1 , qui ne I'exploitera pas. 

L'invention tire parti de cette couche de controle 5 (dont la presence 
peut n'etre qu'implicite et resulter de proprietes du systeme Sexploitation ou 
plus generalement de I'erivironnement d'execution des applications dans le 
10 terminal semi-ouvert) pour empecher une application sans confiance 4 
d'emettre elle-meme des requ§tes qui proiiveraient a un serveur I'accord de 
rutilisateur relatif a la question posee. Une telle application ne peut done pas 
elle-meme recueillir I'accord de I'utilisateur sous une forme exploitable par le 
serveur 1. 

15 On introduit ainsi dans le terminal 2, entre I'application sans confiance, 

le serveur et I'utilisateur, un composant logiciel de confiance 8 dont on s'est 
assure au prealable du comportement "honnete". En pratique, cette assurance 
proviendra souvent du constructeur du terminal semi-ouvert. Le composant de 
confiance 8 ne peut pas §tre remplace ou modifie par une application sans 

20 confiance, ce qui est assure par le systeme semi-ouvert lui-meme, pour qui une 
application de confiance doit rester de confiance. II n'y a done pas de risque 
que le composant 8 se comporte en cheval de Troie. Un r6le principal du 
composant de confiance 8 est de recueillir I'accord de I'utilisateur pour le 
compte d'une ou plusieurs applications sans confiance 4, au moyen d'une 

25 interface utilisateur 9 du terminal. 

Le composant de confiance 8 n'est pas limite dans les requetes qu'il 
peut emettre, ou du moins il subit des restrictions moins severes que les 
applications sans confiance 4. Dans I'exemple sch6matise par la figure 2 ci- 
dessus, il n'est pas contrdle par la couche de controle 5. 

30 On s'interesse a une application 3 ou 4 qui desire prouver a un serveur 

distant 1 qu'elle a obtenu I'accord de I'utilisateur pour une question donnee. 
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Elle dispose initialement de l'enonc6 de la question ainsi que d'une donnee 
d'adressage permettant de contacter le serveur distant, par exemple une 
indication de type URL ("Uniform Resource Locator"). 

Les communications de ces applications 3, 4 sont soumises aux regies 
5 suivantes: 

- les applications peuvent effectuer des communications distantes par 
I'intermediaire des ressources 6 et du reseau R, mais ces 
communications sont limitees par le systeme Sexploitation semi-ouvert 
qui incorpore une couche logique de contrdle 5; 
10 - tout serveur distant 1, ayant connaissance des limites appliquees, peut 



determiner si les messages qu'il recoit proviennent duplications de 
confiance ou non, en examinant si les limites sont appliquees; 



6gard etre vu comme appartenant a la meme famille que les applications 
de confiance 3. 

Une application sans confiance qui desire obtenir I'accord de 
i'utilisateur sur une question donn6e et prouver cet accord a un serveur distant 
20 1 foumit au composant de confiance 8 I'enonce de la question ainsi que 
I'adresse du serveur. Le composant de confiance 8 presente alors la question a 
I'utilisateur au moyen de I'interface 9. La decision de I'utilisateur (accepter ou 
refuser, I'absence de reponse pass6 un certain delai pouvant §tre interpretee 
comme un refus) est recueillie par le composant de confiance. 

25 Si la decision recueillie est un accord, une requete hors des limites 

appliquees aux applications sans confiance est envoyee par le composant de 
confiance au serveur a I'adresse prec6demment indiquee par I'application 4. 
Cette requete contient: 

- Tenoned de la question 

30 - la reponse de I'utilisateur 



15 



- le composant de confiance 8 a la possibilite d'effectuer des 
communications hors des limites imposees aux applications sans 
confiance 4, mais aussi dans ces limites s'il le souhaite. II peut a cet 
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Le serveur 1 virifie, implicitement ou explicitement, que la requite a 
bien ete transmise hors des limites appliquees aux applications sans confiance, 
et repond a cette requite apres validation. La reponse a la requete est 
finalement transmise par le composant de confiance 8 a I'application sans 
5 confiance 4. 

En cas de disaccord de I'utilisateur observe par le composant de 
confiance 8, celui-ci peut transmettre directement a I'application 4 une reponse 
indiquant I'echec. La reponse negative de I'utilisateur n'est qu'optionnellement 
transmise au serveur 1 dans ce cas. 

10 S'il fait confiance au "composant de confiance" 8, le serveur distant 1 

est assure que les requites hors limites qu'il recoit correspondent bien a des 
questions qui ont ete posies a I'utilisateur et que le choix de I'utilisateur a ete 
correctement recueilli. Une application sans confiance ne peut pas simuler ce 
comportement. Le risque de cheval de Troie est done ecarte. 

15 Si la verification par le serveur 1 de la requite censee indiquer I'accord 

de I'utilisateur montre qu'elle a ete transmise dans les limites appliquees aux 
applications sans confiance, cette requite n'est pas interpretie comme etant 
reprisentative de I'accord de I'utilisateur. Ce refus du serveur peut 
optionnellement itre notifie en retour au terminal. 

20 Naturellement, la question prisentie a I'utilisateur peut appeler une 

riponse de tout type, plus riche que "oui/non". La question peut notamment 
prendre la forme d'un formulaire dans lequel plusieurs entrees seraient a 
renseigner par I'utilisateur. Dans ce cas, les diffirentes entries renseignies 
par I'utilisateur peuvent itre transmises au serveur apres que le composant de 

25 confiance 8 a demande et obtenu une validation de la part de I'utilisateur. 

Dans la description qui precede, I'application sans confiance 4 ginere 
elle-mime le texte de la question. Si on prefere que le serveur 1 ginire le 
texte de la question, on peut par exemple procider comme suit: 



- une application sans confiance 4 soumet au composant de confiance 8 



30 



I'adresse d'un serveur 1 (par exemple une URL) et une requite 
appropriie a lui envoyer pour obtenir I'inonci de la question a poser; 




WO 2004/066581 ^■T/FR2003/003225 

-12- 

- le composant de confiance 8 emet la requete via le reseau R afin de 
demander a ce serveur 1 I'enonce de la question. La requete est de 
preference passee par la couche de controle 5 afin de garantir qu'elle soit 
dans les limites autorisees pour les applications sans confiance 4; 

5 - le serveur 1 renvoie I'enonce de la question, en relation avec une 

reference a rappeler ulterieurement lors de la transmission de I'accord de 
I'utilisateur; 

- le composant de confiance 8 pr§sente la question a I'utilisateur comme 
precedemment; 

10 - I'utilisateur fait sa decision; 

- la decision de I'utilisateur est recueillie par le composant de confiance 8; 

- en cas d'accord, le composant de confiance 8 emet une requete vers le 
serveur 1 , cette fois-ci hors des limites imposees aux applications sans 
confiance, en incluant la reference de I'enonce et stipulant que 

15 I'utilisateur a bien donne son accord (la reference peut etre optionnelle, 

auquel cas le composant de confiance repete I'enonce de la question 
dans la requete transmise a cette etape; de facon generate, il suffit que la 
question posee soit suffisamment identifiee dans le message transmis au 
serveur pour indiquer I'accord de I'utilisateur); 

20 - le serveur 1 valide la requete en verifiant qu'elle est bien recue hors des 

limites imposees aux applications sans confiance, et repond a cette 
requdte; 

- la reponse est transferee a ('application qui a initie la demande. 

Comme on s'est assure de passer la requete provenant directement de 
25 I'application sans confiance 4 par la couche de controle 5, le serveur 1 reste 
assure que les requetes hors limites qu'il recoit du composant de confiance 8 
resultent bien d'un accord explicite de I'utilisateur. 

Dans un mode de realisation particulier de I'invention, le terminal 
dispose d'une machine virtuelle Java, pouvant correspondre au module 6 dans 
30 I'illustration des figures 1 et 2. La machine virtuelle permet d'executer des 
applications telechargees ecrites dans le langage de programmation Java mis 
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au point par la societe Sun Microsystems, Inc. Toutes les Instructions du 
langage Java sbnt executees par la machine virtuelle, qui fait appel aux 
fonctions systeme aprds un certain contrdle. Pour les applications Java, on est 
bien dans un environnement semi-ouvert puisqu'il n'y a pas d'appel sans 
5 controle aux fonctions systeme. 

L'application sans confiance 4 est alors ecrite en langage Java. 

Dans ce mode de realisation, les protocoles mis en jeu pour les 
^changes du terminal 2 sur le r§seau R sont les protocoles HTTP (RFC 1945 
("Request For Comments"), publiSe en mai 1996 par I'lETF ("Internet 

10 Engineering Task Force")), TCP (RFC 793, IETF, septembre 1981) et IP (RFC 
791, IETF, septembre 1981). La limite appliquee aux applications sans 
confiance est qu'elles ne peuvent pas adresser de requetes vers les URL de 
type: "http: //<serveur>/<chemin>/accord?<suite>'\ oCl <serveur> 
est un nom de serveur quelconque, <chemin> est une suite de chaTnes de 

15 caracteres de la forme "repertoire_l/r6pertoire_2/.../repertoire_n" 
et <suite> est une chaTne de caracteres quelconque. Cette limite est bien sQr 
un exemple, n'importe quelle autre limite pouvant faire I'affaire. Le service est 
h6berg6 par un serveur HTTP. 

Le composant de confiance 8 peut alors §tre implements dans la 
20 machine virtuelle Java par la classe UserConf irmation. II est accessible 
depuis les applications Java 4 par une fonction de classe: inputstream 
UserConf irmation, ask (String url, String question) dont le 
fonctionnement est le suivant. Lorsqu'une application sans confiance 4 appelle 
la fonction UserConf irmation. ask (String url, String question): 

25 - le composant de confiance 8 ouvre une fenetre ou bien prend le controle 

du terminal sur I'application en cours d'execution; 

- la question dont Penonc6 est donn6 par la chaTne de caracteres 
"question" est affichee a Tecran, et deux choix sont proposes a 
I'utilisateur, a savoir "ok" et "Annuler"; 
30 - si Tutilisateur donne son accord, en choisissant "ok": 
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• le compdsant de confiance 8 envoie sur le reseau R la requete 
HTTP formee par la concatenation (i) de I'URL donnee en 
parametre ("url"), (il) de la chaTne Vaccord?question=", (iii) 
de I'enonce de la question posee a I'utilisateur (encodee au 

5 format d'encodage dans I'URL x-www-urlencoded), et de la 

chaTne "&reponseOK". Ce comportement n'est bien sQr qu'un 
exemple qui correspond a la limitation appliquee aux requetes 
sortant des applications Java. Un serveur est assure par cette 
combinaison que les requetes envoyees a ce stade par le 

10 composant de confiance n'auraient pas pu etre envoyees par les 

applications Java, ce qui repond au besoin; 

• lorsque le composant de confiance 8 recoit ensuite la r^ponse du 
serveur 1 (ou une exception si le serveur n'est pas disponible), il 
retourne a I'application appelante 4 un objet Inputstream 

15 permettant a celle application de connaTtre la reponse du serveur; 

- si I'utilisateur ne donne pas son accord, en choisissant "Annuler": 

• le composant de confiance 8 renvoie une exception a ('application 
appelante 4. 

Pour illustrer ce mode de realisation particulier, on considere le cas ou 
20 le serveur gere un service de micropaiement effectuant des paiements en ligne 
pour le compte de I'utilisateur sur simple accord de ce dernier. Les paiements 
sont debites d'un compte correspondant a I'utilisateur. Lorsqu'il recoit un ordre 
de paiement, ce service veut done s'assurer que cet ordre est bien confirme 
par I'utilisateur, et n'est pas en provenance d'un programme Java mal 
25 intentionne qui n'aurait presente aucune question a I'utilisateur, ou bien qui lui 
aurait presente une question trompeuse. Ce service est bien entendu un 
exemple, n'importe quel autre service demandant I'accord de I'utilisateur 
pouvant etre realise grace a cette technique (publication de documents, gestion 
de fichiers, messagerie, etc.) 

30 Dans cet exemple, le service de paiement contrSle le site web 

"paiement . com". Lorsqu'une application sans confiance souhaite proposer un 
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paiement a I'utilisateur, elle appelle la fonction UserConf irmation . ask en 
lui donnant comma parametres: 

• comme URL: http : / /paiement . com/paiement 

• comme enonce de question: "Payer 1€ a Acme Co . ?" 

5 Le composant de confiance 8 prend le controle du terminal 2, et 

demande a I'utilisateur "Payer le a Acme Co.? OK / Annuler". Si 
I'utilisateur choisit le lien "ok", le composant de confiance emet la requete 
"http : //paiement . com/paiement/accord?question=payer+l€+a+Ac 
me+co. ?&reponse=OK" et transmet la reponse du serveur a ('application 

10 appelante 4, en lui redonnant la main. 

Si I'utilisateur choisit le lien "Annuler", le composant de confiance 8 
n'emet aucune requete et retourne une exception a I'application appelante 4. 

Si une application 4 tente de demander directement la page 

"http : / /paiement . com/paiement /accord?question=payer+l€+a+Ac 
15 me+co. ?&reponse=OK", cette requete est refusee par la limitation appliquee 
aux applications sarts confiance. 

Comme autre illustration du procede selon I'invention, on considere le 
cas ou le serveur gere un service de commerce electronique. Dans le cadre 
d'un tel service, le client est amene a remplir un formulaire de commande. Ce 
20 formulaire est a envoyer selon la methode HTTP POST a I'adresse 

"http://service.com/commande". 

Le composant de confiance peut alors etre implements dans la 
machine virtuelle Java. II est accessible des applications Java par une fonction 

"UserConf irmation. askForm (String url, byte[] formulaire)". 

25 Lorsque cette fonction est appelee par une application Java 4, le 

composant de confiance 8: 

• affiche a I'ecran le formulaire contenu dans le tableau "formulaire" 
passe en parametre de la fonction. Ce formulaire est par exemple dans 
un format XML; 
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• laisse I'utilisateur remplir les champs du formulaire et lui demande de le 
valider en choisissant "ok" ou "Annuler" a la fin du formulaire; 

• envoie une requete HTTP POST lorsque I'utilisateur valide le formulaire, 
a I'URL "url+/accord?", cette requete contenant le formulaire qui a ete 

5 presente a I'utilisateur, ainsi que les donnees saisies par I'utilisateur dans 

les differents champs. 

Si une application Java sans confiance 4 tente d'acceder directement a 
I'adresse "url+ /accord?", la requete sera refusee par la couche de contrdle. 

Par ailleurs, une application pourrait tenter d'induire en erreur 
10 I'utilisateur en lui faisant remplir un formulaire comportant les memes entrees 
que le formulaire authentique, mais avec des libelles differents. Cette attaque 
est egalement dejouee par le fait que le formulaire est transmis au serveur 1 
par le composant de confiance 8. De cette facon, le serveur 1 peut en effet 
verifier que le formulaire rempli par I'utilisateur est bien un formulaire legitime. 

15 On a pris pour clarifier I'expose un exemple simple de limitation 

imposee aux applications sans confiance, a savoir que certaines URL ne sont 
pas accessibles, ce qui est contr6le au moment de remission d'une requete. 
Neanmoins, n'importe quelle autre limitation serait acceptable. 

On peut notamment utiliser un blocage complet de tout acces au 
20 reseau R pour les applications sans confiance 4, un blocage selectif autorisant 
seulement les requetes vers le site web d'origine d'une application telechargee, 
etc. 

La limitation peut aussi se rapporter a un marquage specifique associe 
soit aux applications sans confiance 4, soit aux applications de confiance 3. 
25 Chaque requete issue d'une application sans confiance 4, emise sur le reseau 
R a destination du serveur 1, est alors contrainte par la couche de contrdle 5: 
IV soit a inclure un marquage associe a la famille des applications sans 
confiance, 

121 soit a ne pas inclure un marquage associe a la famille des applications 
30 de confiance, ce marquage etant alors inclus dans certaines au moins 
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des requetes emises sur le r6seau R et issues cTapplications de 
confiance. 

Dans le cas le composant de confiance 8 n'appose pas le 
marquage dans les requetes 6mises pour indiquer Paccord de I'utilisateur, ce 
5 qui assure au serveur 1 que cet accord provient bien de I'utilisateur. Le 
composant de confiance 8 peut en revanche marquer la requete emise sur le 
reseau R pour obtenir I'enonce de la question a poser dans le cas ou cet 
enonc6 n'est pas fourni directement par ('application 4. 

Inversement, dans le cas 121, le composant de confiance 8 appose le 
10 marquage dans les requetes 6mises pour indiquer I'accord de I'utilisateur, et le 
cas 6cheant il ne marque pas la requete emise sur le reseau R pour obtenir 
T6nonce de la question & poser. 

Dans I'exemple ou le composant de confiance 8 fait partie d'une 
machine virtuelle Java 6, le marquage du cas /1/ consiste par exemple en ce 
15 que le champ d'en-tete "User-Agent" des requetes HTTP (cf. section 10:15 de 
la RFC 1945 precitee) contienne une chame specifique telle que 
"Application sans confiance: VM Java 1.2" qui indique par sa 
presence que la requete n'est pas en provenance d'une application de 
confiance. Une mention inverse peut etre prevue dans le cas 121. 
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REVENDICATIONS 



1. Proc6de de communication entre une premiere unite (2) et une 
seconde unite (1) par Pinternrtediaire d'un reseau de telecommunication (R), 
dans lequel ia premtere unite comporte une premiere famille duplications (4) 

5 et une seconde famille ^applications (3) ayant des capacites de 
communication sur le reseau au-dela des capacites de communication des 
applications de la premiere famille, le procede comprenant les etapes 
suivantes: 

/a/ un composant de confiance (8) appartenant d la seconde famille 
10 ^applications obtient l'6nonce d'une question & poser d un utilisateur 

de la premtere unite dans le cadre de I'execution d'une application (4) 
de la premiere famille; 

Ibl le composant de confiance pr6sente la question par Tintermediaire 
d'une interface d'utilisateur (9) et recueille une reponse de Putilisateur; 
15 et 

Id pour au moins un type de reponse de Putilisateur, le composant de 
confiance transmet a la seconde unite, par Pintermediaire du reseau, 
au moins un message identifiant la question presentee et indiquant la 
reponse recueillie, ledit message 6tant transmis dans des conditions 
20 inaccessibles aux applications de la premiere famille. 

2. Proc§de selon la revendication 1 , dans lequel la question presentee 
est identiftee dans le message de T6tape Id en incluant I'enonce de la question 
dans ledit message. 

3. Proc&te selon la revendication 1 ou 2, dans lequel pour au moins un 
25 autre type de reponse traduisant un refus de I'utilisateur par rapport a la 

question presentee, le composant de confiance (8) indique le refus a ladite 
application (4) de la premiere famille. 
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4. Proc6d§ selon la revendication 3, dans lequel pour le type de 

rSponse traduisant un refus de Putilisateur par rapport a la question presentee, 
le composant de confiance (8) ne transmet pas a la seconde unite (1) le 
message de Petape Id. 

5 5. Proc§d§ selon Tune quelconque des revendications pr§cedentes, 

dans lequel la seconde unite (1) valide la r6ponse de Putilisateur & reception du 
message transmis & Petape Id en s'assurant qu'il a bien 6te transmis dans des 
conditions inaccessibles aux applications de la premiere famille. 

6. Proc6d6 selon la revendication 5, dans lequel apres validation de la 
10 r§ponse de Putilisateur, la seconde unite (1) retourne un message de reponse 

au composant de confiance (8) par Pintemrtediaire du reseau (R). 

7. Proc6de selon la revendication 6, dans lequel le composant de 
confiance (8) indique a ladite application (4) de la premiere famille la teneur du 
message de reponse re?u de la seconde unite (1). 

15 8. Proc6de selon Pune quelconque des revendications prec6dentes, 

dans lequel Penonce de la question est indique directement au composant de 
confiance (8) § Petape /a/ par ladite application (4) de la premiere famille. 

9. ProcedS selon la revendication 8, dans lequel ladite application (4) 
de la premiere famille indique une adresse de la seconde unite (1) avec 

20 P6nonc§ de la question a P6tape /a/. 

10. Proced§ selon Pune quelconque des revendications 1^7, dans 
lequel P6tape laJ comprend les sous-etapes suivantes: 

/a1/ ladite application (4) de la premiere famille indique au composant de 
confiance (8) une adresse de la seconde unite (1) ainsi qu'une 
25 requete d soumettre pour obtenir Penonce de la question de la part de 

la seconde unite; 
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/a2/ le composant de confiance emet la requete a I'adresse indiquee, par 
I'intermediaire du reseau (R); 

/a3/ le composant de confiance recupere I'enonce de la question dans une 
reponse a la requete retournee par la seconde unite par 
i I'intermediaire du reseau. 



11. Procede selon la revendication 10, dans lequel la requete est emise 
par le composant de confiance (8) a la sous-etape /a2/ dans des conditions 
accessibles aux applications de la premiere famille. 

12. Procede selon la revendication 10 ou 1 1, dans lequel la reponse a la 
10 requete retournee par la seconde unite (1) inclut en outre une reference que le 

composant de confiance (8) memorise puis insere dans le message transmis a 
I'etape Id pour identifier la question presentee. 

13. Procede selon Tune quelconque des revendications precedentes, 
dans lequel ladite application (4) de la premiere famille est un programme ecrit 

15 en langage Java et le composant de confiance (8) est incorpore a une machine 
virtuelle Java (6) dont est pourvue la premiere unite (2). 

14. Procede selon Tune quelconque des revendications precedentes, 
dans lequel les applications (3) de la seconde famille ont la capacite d'acceder, 
par I'intermediaire du reseau (R), a au moins une URL associee a la seconde 

20 unite (1 ) et inaccessible aux applications (4) de la premiere famille. 

15. Procede selon Tune quelconque des revendications 1 a 13, dans 
lequel les applications (4) de la premiere famille ne sont pas capables 
d'acceder au reseau (R). 

16. Procede selon Tune quelconque des revendications 1 a 13, dans 
25 lequel les applications (4) de la premiere famille ont la capacite, dans un 

protocole de transfert determine, de n'acceder qu'a un seul site distant ne 
comportant pas la seconde unite (1). 
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17. 



Procidi selon Tune quelconque des revendications 1 a 13, dans 



lequel on contraint chaque requite issue d'une application (4) de la seconde 
famille, emise sur le reseau (R) a destination de la seconde unite (1), a inclure 
un marquage associe a ia seconde famille d'applications (3). 



lequel on contraint chaque requite issue d'une application (4) de la seconde 
famille, emise sur le reseau (R) a destination de la seconde unite (1), a ne pas 
inclure un marquage associe a la premiere famille, ledit marquage etant inclus 
dans certaines au moins des requites emises sur le reseau et issues 
10 d'applications (3) de la premiere famille. 

19. Procidi selon la revendication 17 ou 18, dans lequel les requites 
comprennent des requites HTTP, et le marquage est insere dans les en-tites 
des requites HTTP. 

20. Composant logiciel de confiance pour une premiire uniti (2) 
15 capable de communiquer avec une seconde uniti (1) par I'intermediaire d'un 

reseau de telicommunication (R), la premiire uniti comportant une premiire 
famille d'applications (4) et une seconde famille d'applications (3) ayant des 
capacitis de communication sur le reseau au-dela des capacites de 
communication des applications de la premiire famille, le composant de 
20 confiance (8) appartenant a la seconde famille d'applications et incluant des 
instructions pour commander les itapes d'un procidi selon I'une quelconque 
des revendications 1 a 19 lors d'une exicution du composant dans la premiere 
uniti. 



5 18. 



Procidi selon I'une quelconque des revendications 1 a 13, dans 



25 



21. Terminal de communication, incorporant un composant logiciel de 

confiance selon la revendication 20 pour communiquer avec une uniti distante 
(1) par I'intermediaire d'un riseau de tilicommunication (R). 
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